Framework system

ABSTRACT

Disclosed is a framework system improved such that flow of complex business logic for processing a variety of messages may be easily defined and changed without need for programming. Messaging service(s)  15  may relay message(s) between client(s)  11, 13  and framework service(s)  16 . Among request message(s) relayed from client(s)  11, 13  to framework service(s)  16  there may be message(s) comprising subject ID(s) associated with subject(s) of such message(s). Framework service(s)  16  may possess a plurality of sets of business logic  22  and flow definition file(s)  23 . Flow definition file(s)  23  may comprise a plurality of definition sentences respectively corresponding to various subject IDs, and each such definition sentence may indicate schedule(s) for execution of business logic. Framework service(s)  16 , upon receiving request message(s) from messaging service(s)  15 , may select one or more sets of business logic for execution in accordance with execution schedule(s) corresponding to subject ID(s) of such message(s) indicated in definition file(s). Flow definition file(s)  23  can be rewritten at desired time or times notwithstanding the fact that framework service(s)  16  may be operational at such time(s). In the event that a plurality of sets of business logic are to be executed in linked fashion, framework service(s)  16  may execute subsequent business logic synchronously and/or asynchronously with respect to first business logic pursuant to execution schedule(s) indicated in definition sentence(s).

FIELD OF ART

The present invention pertains to a framework system capable ofexecuting one or more selected sets of business logic responsive to oneor more messages from one or more clients.

BACKGROUND OF ART

Such a framework system typically comprises one or more serversconnected so as to be capable of communication with one or more clients.Such a framework system has conventionally been provided with the twobasic functionalities represented by messaging service functionality andframework service functionality. A messaging service is a service thatprocesses messages communicated between or among client or clients andserver or servers, and/or between or among server or servers and serveror servers. A framework service possesses one or more but ordinarily aplurality of sets of business logic (business operation process orprocesses), and performs one or more transactions by synchronously or asynchronously executing one or more selected sets of business logicresponsive to one or more messages from one or more clients.

However, in the conventional example described above, schedules forprocessing of business logic by framework services are defined by fixedprogramming. This makes it difficult to flexibly define flows of complexbusiness logic to accommodate diverse varieties of messages.

Furthermore, a plurality of sets of business logic may be executed inturn in response to message or messages from client or clients. Forexample, logging of a purchase, update of inventory, entry into anaccounts payable ledger, and the like might be performed in response toa request from a client for logging of a purchase. In such a case, in aconventional system, business logic for logging of purchases and othersuch front-office-type operations might for example be executedsynchronously with respect to the message, with business logic forupdate of inventory, entry into an accounts payable ledger, and othersuch back-office-type operations being executed through batch processingcarried out at night. This means that it is necessary to wait until thenext day before the results of back-office processing will becomeavailable. But to be able to promptly take advantage of a prospectivetransaction it is desirable that back-office business logic be executedas soon as possible so that those results can be made available quickly.

Furthermore, in the case of a system employing a plurality of frameworkservers, messages may also be sent between and/or among frameworkservers as they work together to execute a group of sets of businesslogic. The status or statuses (e.g., the type of business logic storedtherein, whether operating normally or not, whether busy or not, etc.)of any particular server will ordinarily be different from the status orstatuses of other servers, and will moreover change as time goes on.This complicates scheduling, i.e., the decision of which server orservers to employ for execution of business logic.

DISCLOSURE OF INVENTION

It is an object of the invention to provide a framework system in whichflow of business logic is not programmed but is instead easily definedand changed.

It is another object of the present invention to provide a frameworksystem permitting a group of sets of business logic to be executed ifnot completely in real time at least as close as possible to real time.

It is yet another object of the present invention to, in a systemcomprising a plurality of framework servers, permit scheduling of agroup of sets of business logic to be carried out appropriately incorrespondence to status or statuses of those servers.

A framework system in accordance with one aspect of the presentinvention and connected so as to be capable of communication with one ormore clients comprises one or more framework services which is or areassociated with a plurality of sets of business logic and which,responsive to one or more request messages from one or more clients, isor are capable of executing one or more selected sets of business logicand outputting one or more reply messages to one or more clients; one ormore messaging services interposed between client or clients andframework service or services and capable of relaying one or moremessages between client or clients and framework service or services;and one or more flow definition files associated with one or moreframework services. One or more request messages may comprise one ormore subject IDs identifying one or more subjects of that or thosemessages. One or more flow definition files may comprise a plurality ofdefinition sentences respectively corresponding to a plurality ofdifferent subject IDs, each such definition sentence indicating one ormore schedules for execution of one or more prescribed sets of businesslogic. One or more framework services, upon receiving one or morerequest messages from one or more messaging services, may reference oneor more definition sentences present within one or more definition filesand corresponding to one or more subject IDs of one or more receivedrequest messages, and select one or more sets of business logic forexecution in accordance with one or more execution schedules indicatedby one or more referenced definition sentences.

In a preferred embodiment, such a framework system further comprises oneor more flow definition update components capable of updating one ormore flow definition files while one or more framework services is orare operational.

In a preferred embodiment, one or more flow definition files maycomprise one or more flow definition sentences indicating one or morelinked execution schedules for linked execution of a plurality of setsof business logic comprising one set of first business logic and one ormore sets of subsequent business logic (such flow definition file orfiles need not, of course, comprise such definition sentence orsentences defining such linked execution schedule or schedules). Suchlinked execution schedule or schedules may comprise indication of stateor states of one or more linking mode flags for selection of synchronousor asynchronous execution of subsequent business logic. In addition,such framework service or services may, in the event of execution of aplurality of sets of business logic in accordance with linked executionschedule or schedules, execute subsequent business logic synchronouslyor asynchronously with respect to execution of first business logic inaccordance with linking mode flag or flags present within linkedexecution schedule or schedules.

In a preferred embodiment, linked execution schedule or schedules maycomprise information concerning first business logic and informationconcerning one or more secondary request messages for subsequentbusiness logic. In addition, such framework system or systems may, inthe event of execution of a plurality of sets of business logic inaccordance with linked execution schedule or schedules, execute firstbusiness logic, thereafter use the results of execution of firstbusiness logic to create secondary request message or messages, and sendsuch secondary request message or messages to messaging service orservices. Such framework system or systems may thereafter, upon receiptof such secondary request message or messages from messaging service orservices, execute subsequent business logic in accordance with executionschedule or schedules of definition sentence or sentences correspondingto such secondary request message or messages.

In a preferred embodiment, moreover, one or more messaging services maybe equipped with one or more nonvolatile message queues capable ofprotected storage of such secondary request message or messages. Suchmessage queue or queues may be capable of preventing deletion ofsecondary request message or messages by continuing to store secondaryrequest message or messages after such secondary request message ormessages has or have been sent to framework service or services. Inaddition, such messaging service or services may be capable of resendingsecondary request message or messages stored in such nonvolatile messagequeue or queues to such a framework system as necessary.

A framework system in accordance with another aspect of the presentinvention and connected so as to be capable of communication with one ormore clients comprises one or more framework services capable ofprocessing one or more request messages from one or more clients andoutputting one or more reply messages to one or more clients; and one ormore messaging services interposed between client or clients andframework service or services and capable of relaying one or moremessages between client or clients and framework service or services. Inaddition, such messaging service or services may be capable of relayingnot only one or more P to P messages such as such request and/or replymessage or messages, but also of relaying one or more P to M messagesbetween client or clients and framework service or services.

In a preferred embodiment, such messaging service or services may haveone or more ring buffers capable of temporarily delaying one or more Pto M messages.

In a preferred embodiment, moreover, P to P messages may respectivelycomprise indication of state or states of one or more protected modeflags indicating whether protected storage is required. In addition,such messaging service or services may have one or more primary messagequeues capable of temporarily delaying one or more P to P messages forwhich protected storage is not required and one or more nonvolatilesecondary message queues capable of temporarily delaying one or more Pto P messages for which protected storage is required.

A framework system in accordance with yet another aspect of the presentinvention and connected so as to be capable of communication with one ormore clients comprises a plurality of messaging services mutuallyconnected in mesh fashion and comprising at least one messaging servicewhich is connected to one or more clients; and a plurality of frameworkservices respectively connected to a plurality of messaging services. Inaddition, a plurality of framework services may be respectively capableof awaiting one or more request messages having one or morepreestablished subject IDs and, upon receipt of one or more requestmessages having such preestablished subject ID or IDs, of processing thereceived request message or messages and of outputting one or more replymessages to one or more clients. In addition, such plurality ofmessaging services may be capable of relaying one or more messagesbetween client or clients and such plurality of framework services andmay be capable of relaying one or more messages between or among suchplurality of framework systems.

In a preferred embodiment, messaging service or services may berespectively capable of monitoring operation of one or more othermessaging services, and, in the event that normal operation of at leastone other messaging service fails to be detected, one or more messagesmay be relayed to one or more other messaging services which is or areoperating normally instead of to such messaging service or serviceswhich is or are not operating normally.

In a preferred embodiment, moreover, messaging service or services maybe respectively capable of monitoring state or states of one or moreframework services respectively connected thereto, and selection ofwhether to relay one or more request messages from client or clients tosuch framework service or services or to one or more other messagingservices may be made in correspondence to monitored state or states.

In a preferred embodiment, moreover, messaging service or services mayhave their own respective management table or tables, one or moresubject IDs of one or more messages awaited by one or more frameworksystems connected to messaging service or services and one or moresubject IDs of one or more messages respectively awaited by one or moreother messaging services connected to messaging service or services maybe registered in such management table or tables. In addition, messagingservice or services, at one or more times when one or more messages isor are received, may reference management table or tables respectivethereto, search for one or more framework services or one or more othermessaging services that awaits or await subject ID or IDs matchingsubject ID or IDs of received message or messages, and relay receivedmessage or messages to framework service or services or other messagingservice or services found as a result of search.

In a preferred embodiment, furthermore, messaging service or servicesmay communicate, to one or more other messaging services, subject ID orIDs of message or messages awaited by such messaging service or servicesbased on content of management table or tables respective thereto. Othermessaging service or services, upon receipt of such communication, mayrespectively additionally register communicated content in managementtable or tables respective thereto if such communicated content is notyet registered in management table or tables respective thereto.

A framework system in accordance with still another aspect of thepresent invention and connected so as to be capable of communicationwith one or more clients comprises one or more framework servicescapable of processing one or more request messages from client orclients and of outputting one or more reply messages to client orclients, and one or more messaging services interposed between client orclients and framework service or services and capable of relaying one ormore messages between client or clients and framework service orservices. Request message or messages from client or clients may beprioritized in a particular fashion. In addition, messaging service orservices may comprise one or more message queues capable of temporarilydelaying such request message or messages and one or more queuemanagement components capable of managing input and/or output of messagequeue or queues. Queue management component or components may beprovided with a prioritized mode by which, at one or more times when aplurality of messages have been stored in message queue or queues, orderor orders in which a plurality of messages are output from message queueor queues is or are controlled in correspondence to respective priorityor priorities of respective message or messages, and with a sequenceprotection mode by which, at one or more times when a plurality ofmessages have been stored in message queue or queues, retrieval of othermessages stored in message queue or queues is prohibited untilcompletion of processing at such framework service or services ofmessage or messages previously retrieved from message queue or queues.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a drawing of the overall constitution of the presentembodiment.

FIG. 2 is a block diagram showing the constitution of a message handledby RtFA server(s) 14.

FIG. 3 is a drawing of the constitution of RtFA servers 14.

FIG. 4 shows an example of a management table 18 associated withmessaging service(s) 15.

FIG. 5 is a drawing of the constitution of connections among a pluralityof RtFA servers.

FIG. 6 is a drawing of the constitution of connections among a pluralityof messaging services.

FIG. 7 is an explanatory drawing showing one way in which message(s)subjected to P to M (one-to-many) processing may be relayed.

FIG. 8 is a flowchart showing an example of P to M communicationprocessing.

FIG. 9 is a flowchart showing an example of P to P (one-to-one)processing.

FIG. 10 is an explanatory drawing showing messaging service loadbalancing functionality.

FIG. 11 is a block diagram showing framework service constitution.

FIG. 12 is a drawing to assist in describing framework serviceoperation.

FIG. 13 shows a simple example of a flow definition file.

FIG. 14 is a block diagram showing a flow definition file update system.

FIG. 15 is a block diagram showing framework service message conversionprocessing functionality.

FIG. 16 is a block diagram showing messaging service message queueconstitution.

FIG. 17 is a flowchart showing operations by which message queuemanagement functionality may store message(s) in message queue(s).

FIG. 18 is a continuation of the flowchart shown in FIG. 17.

FIG. 19 is a block diagram showing a message read component of messagequeue management functionality.

FIG. 20 shows constitution(s) of storage area(s) for prioritized mode.

FIG. 21 shows flow of operations in prioritized mode.

FIG. 22 shows flow of operations in sequence protection mode.

FIG. 23 is a block diagram showing framework service messagediscrimination functionality.

FIG. 24 is a block diagram showing business logic for framework servicemessage conversion.

BEST MODE OF CARRYING OUT INVENTION

Below, an embodiment of the present invention is described withreference to the drawings. FIG. 1 shows the overall constitution of thepresent embodiment.

The present system is made up of presentation layer(s) 1, business logiclayer(s) 2, and data services layer(s) 3.

Presentation layer(s) 1 comprises web (Word Wide Web) client(s) 11, web(Word Wide Web) server(s) 12, and VB (Visual Basic) client(s) 13.

Business logic layer(s) 2 is provided with RtFA server(s) 14, servercomputer system(s) on which framework architecture (referred to in thepresent specification as “RtFA” or “Real Time Framework Architecture”)in accordance with the principles of the present invention has beenapplied. RtFA server(s) 14 comprises server computer system(s)performing messaging service(s) (hereinafter simply “messagingservice(s)”) 15 and server computer system(s) performing frameworkservice(s) (hereinafter simply “framework service(s)”) 16. Messagingservice(s) 15 and framework service(s) 16 are typically implementedusing separate respective computer machines or separate respective setsof computer machines. However, this need not be the case, as it is alsopossible to implement messaging service(s) 15 and framework service(s)16 on the same computer machine or set of computer machines.

Messaging service(s) 15 controls or control the passing of messagesbetween client(s) 11, 13 and RtFA server(s) 14. That is, messagingservice(s) 15 might receive request message(s) for some sort ofprocessing from client(s) 11, 13 and might pass such request message(s)to framework service(s) 16 capable of carrying out such requestedprocessing. Or messaging service(s) 15 might receive reply message(s)indicating results of processing which has been executed from frameworkservice(s) 16 and might furthermore, depending on the situation, receiveadditional request message(s) for subsequent additional processing.Messaging service(s) 15 might send such reply message(s) to client(s)11, 13 and/or might again pass additional request message(s) toframework service(s) 16.

Each message handled by messaging service(s) 15 may comprise subjectID(s), which is or are identification code(s) indicating subject(s) ofthat message (e.g., purchase log request, inventory update request,accounts payable log request, etc.). Such subject ID(s) may be used forthe purpose of selection of destination(s) for such message(s) bymessaging service(s) 15 and/or framework service(s) 16, as will bedescribed below, for which reason they are also called “destinationsubject ID(s).”

Framework service(s) 16 have a plurality of sets of business logic forrespective processing of a variety of types of messages (e.g., purchaseprocessing business logic, inventory processing business logic, accountspayable processing business logic, message conversion business logic,etc.). Upon receipt of some message(s) from messaging service(s) 15,framework service(s) 16 might select business logic for processing ofsuch message(s) based on subject ID(s) of such message(s) and might callsuch selected business logic. Such business logic, upon being called,might carry out processing in correspondence to content of suchmessage(s) and might update data at data services layer 3. Computerprogram(s) for messaging service(s) 15 and framework service(s) 16might, for example, be represented in the JAVA™ language.

Data services layer 3 is provided with database server(s) (“DBserver(s)”) 17.

Communication connection(s) can be established between web client(s) 11and web server(s) 12 via HTTP or socket(s). Direct communicationconnection(s) can be established between web client(s) 11 and RtFAserver(s) 14 via socket(s). Direct communication connection(s) can beestablished between VB client(s) 13 and RtFA server(s) 14 via socket(s).Furthermore, direct communication connection(s) can be establishedbetween web server(s) 12 and RtFA server(s) 14 via socket(s). Moreover,communication connection(s) can be established between RtFA server(s) 14and DB server(s) 17 via JDBC.

FIG. 2 shows the constitution of a message handled by RtFA server(s) 14.

As shown in FIG. 2, a message 10 may be made up of a plurality of servercontrol items and business data. Server control items are various datafor control of RtFA server(s) 14, and may, for example, comprise messagetype(s), protected mode flag(s), priority or priorities, subject ID(s)(destination subject ID(s)), sender information, and so forth.

“Message type(s)” indicates whether such message(s) is or are P to P(Point to Point) or P to M (Point to Many). As used herein, “P to P”refers to communication of message(s) sent from a single computer systemto another single computer system; i.e., one-to-one communication. As anexample of P to P communication, a purchase log request message from aparticular client might be sent to a particular framework service whichperforms purchasing processing. On the other hand, “P to M” refers tocommunication of message(s) sent from one computer system or a pluralityof computer systems to different plurality of computer systems; i.e.,one-to-plurality or plurality-to-plurality communication. As an exampleof P to M communication, a message indicating inventory update resultsfrom one particular framework service might be sent to a plurality ofclient terminals responsible for front-office tasks.

“Protected mode flag(s)” indicates whether the message(s) is to beprotected (i.e., whether to make certain that such message(s) has beensent and processed) (“G”) or not protected (“N”). When message(s) havingprotected mode flag(s) set to “N” is or are received, messagingservice(s) 15 might place such message(s) in message queue(s) employingvolatile semiconductor memory or memories (hereinafter “memoryqueue(s)”). On the other hand, when message(s) having protected modeflag(s) set to “G” is or are received, messaging service(s) 15 mightplace such message(s) in message queue(s) employing nonvolatile diskstorage (hereinafter “DB (database) queue(s)”) and might continue tostore such message(s) in DB queue(s) after such message(s) has or havebeen sent. Accordingly, in the case of message(s) having protected modeflag(s) set to “G,” the same message(s) can be resent in the event ofbad transmission, system failure, or other such problem.

“Priority or priorities” indicates priority level(s) with which suchmessage(s) is or are to be processed. For example, there might be 3priority classes such as high (“H”), normal (“N”), and low (L″). Asdescribed below, at one or more times when there are plurality ofmessages in message queue(s), messaging service(s) 15 may controlorder(s) in which such messages are retrieved from message queue(s) incorrespondence to respective priority or priorities of such messages.

“Subject ID(s) (destination subject ID(s)),” as already mentioned, is orare identification code(s) indicating message subject type(s). Asdescribed below, messaging service(s) 15, upon receipt of message(s),might select computer system(s) (e.g., client(s), framework service(s),other messaging service(s), and/or the like) to serve as destination(s)for such message(s) based on subject ID(s) of such message(s).Furthermore, framework service(s) 16, upon receipt of message(s), mightselect business logic to be called for processing of such message(s)based on subject ID(s) of such message(s).

“Sender information” indicates sender subject(s), IP address(es),computer name(s), and/or the like.

FIG. 3 is a drawing of the constitution of RtFA servers 14.

In the previous description with reference to FIG. 1, only one RtFAserver 14 was indicated. However, as shown in FIG. 3, a plurality ofRtFA servers 14 may actually be provided. While two RtFA servers 14 areprovided in the example shown in FIG. 3, more RtFA servers 14 may alsobe provided.

As shown in FIG. 3, each RtFA server 14 may be provided with onemessaging service 15 and one or more framework service(s) 16, themessaging service 15 and the framework service(s) 16 being connected soas to be capable of mutual communication. A messaging service 15 maymoreover be connected so as to be capable of communication with one ormore client(s) 11, 13. A messaging service 15 may process in parallelfashion a plurality of threads respectively communicating with client(s)11, 13 and framework service(s) 16.

Because there are a plurality of RtFA servers 14, there are a pluralityof sets comprising messaging service 15 and framework services 16. Inaddition, messaging services 15 of the plurality of RtFA servers 14 maybe connected so as to be capable of mutual communication. Messagingservice(s) 15 of each RtFA server 14 may also be provided with thread(s)171 capable of processing communications with messaging service(s) 15 ofother RtFA server(s) 14. The plurality of communication threads 171belonging to each messaging service 15 may respectively possesskeep-alive functionality, this functionality mutually ensuringmaintenance of normal operations between such messaging service 15 andthe client(s) 11, 13, other messaging service(s) 15, and/or frameworkservice(s) 16 connected thereto.

Furthermore, management table(s) 18 such as that shown by way of exampleat FIG. 4 may be associated with each messaging service 15. Managedwithin management table 18 is or are path(s) to be used by suchmessaging service(s) 15 in delivering message(s); in other words,destination(s) for message(s) handled by such messaging service(s) 15.As shown at FIG. 4, type(s), computer ID(s), IP address(es), P to Psubject ID(s), P to M subject ID(s), in-process flag(s), and the likemay be registered in management table(s) 18 for each and every computersystem (client(s) 11, 13, other messaging service(s) 15, and frameworkservice(s) 16) connected to such messaging service(s) 15.

“Type(s)” indicates type(s) of such computer system(s); e.g., whetherframework service(s) (F), messaging service(s) (M), and/or clientterminal(s) (T).

“Computer ID(s)” and “IP address(es)” indicate identification code(s)unique to such computer system(s) and IP address(es) thereof.

“P to P subject ID(s)” indicates subject ID(s) (destination subjectID(s)) of P to P message(s) awaited by such computer system(s) (meaningthat such computer system(s) is or are capable of becomingdestination(s) for such message(s)). A plurality of P to P subject IDsmay be registered for each respective computer system.

“P to M subject ID(s)” indicates subject ID(s) (destination subjectID(s)) of P to M message(s) awaited by such computer system(s) (meaningthat such computer system(s) is or are capable of becomingdestination(s) for such message(s)). A plurality of P to M subject IDsmay be registered for each respective computer system.

“In-process flag(s)” indicates whether (“1”) or not (“0”) thread(s) 171for communication with such computer system(s) is or are involved inongoing P to P communication process(es).

The management table 18 shown in FIG. 4, being an example applicable tothe case of messaging service Mes1 shown at the left side of FIG. 3,contains registered therein all computer systems connected to messagingservice Mes1 shown at left; i.e., the two framework services Frm1 andFrm2, the messaging service Mes2 shown at right, and the three clientterminals PC1, PC2, and PC3. In the present example, a first frameworkservice Frm1 awaits four P to P message types respectively havingsubject IDs of “A,” “B,” “C,” and “D, ” and awaits four P to M messagetypes respectively having subject IDs of “O,” “P,” “Q,” and “R.”

Furthermore, messaging service Mes2 shown at the right side of thedrawing awaits seven P to P message types respectively having subjectIDs of“D,” “E,” “F,” “H,” “I,” and “J” from messaging service Mes1 shownat left, and awaits six P to M message types respectively having subjectIDs of“P,” “T,” and “U” from messaging service Mes1 shown at left.

With reference again to FIG. 3, each messaging service 15, upon receiptof message(s), determines whether such message(s) is or are P to Pmessage(s) or P to M message(s). At one or more times when P to Pmessage(s) is or are received, messaging service(s) 15 might referencemanagement table(s) 18 associated with such messaging service(s) 15 andas shown by way of example in FIG. 4, search for computer system(s)awaiting message(s) having P to P subject ID(s) matching subject ID(s)of such received message(s), select among one or more computer system(s)found as a result of such search one computer system having in-processflag(s) set to “0,” and send such received message(s) to the oneselected computer system. Furthermore, at one or more times when P to Mmessage(s) is or are received, messaging service(s) 15 might referencemanagement table(s) 18 associated with such messaging service(s) 15 andas shown by way of example in FIG. 4, select all computer system(s)awaiting message(s) having P to M subject ID(s) matching subject ID(s)of such received message(s), and send such received message(s) to allselected computer system(s).

FIG. 5 is a drawing of the constitution of connections among a pluralityof RtFA servers. FIG. 6 is a drawing of the constitution of connectionsbetween or among messaging service(s) and/or framework service(s) withina plurality of RtFA servers 14.

As shown at both the top and bottom halves of FIG. 5, each RtFA server14 may be connected so as to be capable of mutual communication with allother RtFA server(s) 14. That is, as shown in FIG. 6, messagingservice(s) 15 of each RtFA server 14 may be connected so as to becapable of mutual communication with messaging service(s) 15 of allother RtFA server(s) 14. A plurality of components are said to beconnected in “mesh” fashion when they are respectively connected in thisway so as to be capable of mutual communication with all other suchcomponents. Furthermore, as shown in FIG. 6, each messaging service 15may be connected so as to be capable of direct communication with aplurality of framework services 16.

Each messaging service 15 among a plurality of messaging services 15connected in mesh fashion in this way might execute the aforementionedkeep-alive functionality during a prescribed time period; e.g., atstartup time. That is, at startup, each messaging service 15 mightconnect in turn to all other messaging service(s) already registered inmanagement table(s) 18 thereof and communicate, to all other messagingservice(s) to which it is connected, subject ID(s) of message(s) awaitedby client(s) 11, 13 and framework service(s) 16 connected thereto. Suchcommunicated subject ID(s) might be registered in management table(s) ofother messaging service(s) as subject ID(s) of message(s) awaited bysuch messaging service 15 from such other messaging service(s).Furthermore, each messaging service 15, in the event that connectioncannot be made to other message(s) despite attempt(s) to connectthereto, might at fixed intervals thereafter make a plurality ofsubsequent attempts to connect thereto. Furthermore, each messagingservice 15, at one or more times when connection request(s) is or arereceived from other messaging service(s) which are not yet registered inmanagement table(s) 18 thereof, might connect to such unregisteredmessaging service(s), carry out exchange with such unregisteredmessaging service(s) of subject ID(s) and/or the like respectivelyawaited by each, and might register such messaging service(s) inmanagement table(s) 18 thereof. By virtue of such keep-alivefunctionality, in the event that particular messaging service(s) 15 isor are not operating normally (e.g., due to system crash) the other,normally operating messaging service(s) 15 can respectively remove suchparticular messaging service(s) 15 which is or are not operatingnormally from message relay path(s) and reference its or their ownmanagement table(s) 18 to automatically select different relay path(s).

Next, types of communication services provided by messaging service(s)15 are described with reference to FIGS. 7 through 9. Among the types ofdata distribution services which may be provided by messaging service(s)15 there are the two types represented by P to M (one-to-many)processing and P to P (one-to-one) processing.

As mentioned above, P to M communication processing is processing bywhich messaging service(s) 15 might distribute received P to Mmessage(s) to all computer system(s) awaiting same based on P to Msubject ID(s) of respective computer system(s) registered in managementtable(s) 18 such as is shown by way of example in FIG. 4. For example, Pto M communication processing might be used every time that marketinformation is updated, to distribute from anywhere between 1 and n RtFAserver(s) to n client(s) a message containing such updated marketinformation.

On the other hand, as mentioned above, P to P communication processingis processing by which messaging service(s) 15 might send received P toP message(s) to one among a number of computer system(s) awaiting samebased on P to P subject ID(s) of respective computer system(s)registered in management table(s) 18 such as is shown by way of examplein FIG. 4. For example, P to P communication processing might be used tosend request message(s) from client(s) for particular processing to oneframework service having business logic capable of carrying out suchprocessing.

FIG. 7 shows one example of a way in which message(s) subjected to P toM communication processing may be relayed. Particular P to M message(s)output by particular framework service(s) 16 serving as publisher(s)might be distributed to all messaging service(s) 15 awaiting suchmessage(s), and such message(s) might furthermore be distributed fromsuch messaging service(s) 15 to all client(s) 11, 13 awaiting suchmessage(s).

FIG. 8 is a flowchart showing an example of P to M communicationprocessing. Client T1 serving as subscriber might establish a connectionwith a prescribed messaging service Mes1 via socket(s). Client T1 mightfurthermore register with such messaging service Mes1 a subject ID “X”for P to M message(s) that it awaits. Such messaging service Mes1 mightadd to management table(s) 18 associated therewith a P to M subject IDof “X” for client T1. Client T1, for its part, might await delivery ofmessage(s) from messaging service Mes1. At a time when other messagingservices Mes2, Mes3, which are connected to messaging service Mes1, arethereafter started up, P to M subject ID “X” already registered atmanagement table(s) 18 of messaging service Mes1 might be communicatedto the other messaging services Mes2, Mes3, with P to M subject ID “X”being added to their management tables 18 for messaging service Mes1.

In such a case, upon distribution of P to M message(s) having subject ID“X” from framework service Frm3 serving as publisher, messaging serviceMes3 upon receiving same might reference management table(s) 18associated therewith, identify all messaging service(s) Mes1, Mes2awaiting subject ID “X”, and transfer such message(s) thereto.

Messaging service Mes1 connected to client T1, upon receiving suchmessage(s), might identify client T1, which awaits subject ID “X”, basedon management table(s) 18 associated therewith and might deliver suchmessage(s) to that client T1.

While not shown in the drawings, each framework service may alsocommunicate subject ID(s) of P to M message(s) awaited by that frameworkservice to messaging service(s) capable of direct communication withthat framework service. Doing so will make it possible for P to Msubject ID(s) awaited by that framework service to be registered inmanagement table(s) of such messaging service(s). Such messagingservice(s) might thereafter communicate to all other messagingservice(s) that such framework service P to M message subject ID(s)registered in management table(s) thereof are P to M subject ID(s)awaited by such messaging service(s). Doing so will make it possible forP to M subject ID(s) awaited by that framework service to becomeregistered in management table(s) of all other messaging service(s) aswell. As a result, that framework service would be able to receivemessage(s) having P to M subject ID(s) from any messaging service.

Next, FIG. 9 is a flowchart showing P to P communication processing.

In the same fashion as the registration of P to M subject ID(s) inmanagement table(s) described above, P to P subject ID(s) respectivelyawaited by client(s) and/or framework service(s) capable of directcommunication therewith, and/or P to P subject ID(s) respectivelyawaited by any and/or all of the other messaging service(s), may beautomatically registered in advance in management table(s) of eachmessaging service.

Under such circumstances, as shown in FIG. 9, a particular client PC1might establish a connection with a prescribed messaging service Mes1.

If P to P request message(s) having a particular subject ID “A” is orare then sent from client PC1, a messaging service Mes1 receiving samemight reference its management table(s) 18, select one computer system,e.g., framework service Frm1, from among a number of computer system(s)awaiting such subject ID “A”, and pass such request message(s) thereto(arrow ({circumflex over (1)}). Framework service Frm1 might callbusiness logic corresponding to subject ID “A” of received requestmessage(s), perform processing pursuant to such message(s), and returnreply message(s) indicating results of such processing to messagingservice Mes1 (arrow {circumflex over (3)})). In addition, messagingservice Mes1 might send such reply message(s) to client PC1 in the formof a reply thereto. Client PC1, upon obtaining such reply message(s),might release its connection with messaging service Mes1.

Alternatively, instead of or in addition to sending request message(s)having subject ID “A” and received from client PC1 to framework serviceFrm1 as in the example described above, messaging service Mes1 mightsend same to another messaging service Mes2 awaiting subject ID “A”(arrow {circumflex over (2)})). Such a situation might occur if forexample framework service Frm1 is engaged in ongoing process(es) butmessaging service Mes2 is not engaged in ongoing process(es). In such asituation, messaging service Mes2, upon receiving such requestmessage(s), might reference its management table(s) 18, select acomputer system, e.g., framework service Frm2, awaiting such subject ID“A”, and pass such request message(s) thereto for processing (arrow({circumflex over (1)}). Upon return thereto from framework service Frm2of reply message(s) indicating results of processing (arrow({circumflexover (5)}), messaging service Mes2 might return such reply message(s) tomessaging service Mes1 (arrow ({circumflex over (6)}), and messagingservice Mes1 might moreover return such reply message(s) to client PC1.

As described above, a messaging service 15 may send message(s) not onlyto framework service(s) 16 with which it is capable of directcommunication but may also send message(s) to other framework service(s)via other messaging service(s). This permits load balancing to takeplace among a plurality of RtFA servers 14.

FIG. 10 is an explanatory drawing showing a load balancing functionalitywhich messaging service(s) may possess.

As shown in FIG. 10, respective framework service(s) 16 at respectiveRtFA server(s) 14 may process in parallel fashion a plurality of threads19 communicating with messaging service(s) 15. Furthermore, eachmessaging service 15 may be provided with message queue(s) 15 a capableof temporarily holding message(s) received from client(s).

Each message stored in message queue(s) 15 a of messaging service(s) 15might be passed to some framework service(s) 16 corresponding to subjectID(s) of such message in accordance with management table(s) associatedwith such messaging service(s) 15. In such a case, such messagingservice(s) 15 may pass such message to specific framework service(s) 16capable of direct communication therewith and awaiting such subjectID(s). But if at such time none of thread(s) 19 of such specificframework service(s) 16 is or are open (it or they is or are busy, beingengaged in ongoing process(es)), such messaging service(s) 15 might passsuch message not to such framework service(s) 16 which is or are busybut to other messaging service(s) 15 awaiting such subject ID(s). Suchother messaging service(s) 15 receiving such message may pass suchmessage to specific framework service(s) 16 awaiting such subject ID(s)and with which such other messaging service(s) 15 is or are capable ofdirect communication. To make such relay of message(s) possible, eachmessaging service 15 might regularly monitor its message queue(s) 15 a,and in the event that message(s) waiting to be processed is or arepresent in such message queue(s) 15 a might immediately retrievemessage(s) from such queue(s), refer to its management table(s) so as topromptly determine destination(s) for such message(s), and send suchmessage(s) thereto. This permits load balancing among a plurality ofRtFA servers. Each message may consequently be processed as quickly aspossible, making it possible for back-office tasks which wereconventionally carried out through batch processing at night to becarried out quickly and in almost real-time fashion.

Constitution of framework service(s) 16 is next described.

FIG. 11 shows constitution of a framework service 16.

A parallel processing by a plurality of framework threads 25 mayconstitute the essence of framework service 16. Each framework thread 25might respectively access a previously prepared group of business logic20, and might load and execute specific business logic 22 correspondingto subject ID(s) of message(s) passed thereto from messaging service(s)15. What is here referred to as business logic is a process orprocesses, e.g., programmed using Java code, which carries or carry outthe various types of message processing peculiar thereto. Most of themajor business logic components make requests of database(s) 21 managedby database server(s) 17 for prescribed operation(s) to be carried outin correspondence to message content.

FIG. 12 is a drawing to assist in describing operation of frameworkservice(s) 16.

Operation of business logic associated with framework service(s) 16 canbe broadly categorized into two categories as being either synchronousor asynchronous. There are situations where framework service(s) 16 may,responsive to particular request message(s) from client(s), execute onlya single set of business logic. Furthermore, there are also situationswhere framework service(s) 16 may execute a single set of business logicin direct response to particular request message(s), with one or moresets of business logic being subsequently executed in linked fashiontherewith. FIG. 12 shows an example in which business logic forexecuting purchase processing is executed in direct response to purchaselog request message(s) from client(s) 11, 13, with the two subsequentsets of business logic represented by inventory processing andaccounting processing being executed in linked fashion therewith.

Where only a single set of business logic is to be executed, and this indirect response to request message(s) from client(s), frameworkservice(s) 16 might ordinarily execute such single set of business logicin synchronous fashion and return reply message(s) indicating results ofsuch execution to client(s).

In contradistinction hereto, where a single set of business logic is tobe executed in direct response to request message(s) from client(s),following which one or more subsequent sets of business logic is or areto be executed in linked fashion with respect thereto, frameworkservice(s) 16 might ordinarily execute such initial single set ofbusiness logic in synchronous fashion but could execute such secondand/or following set(s) of business logic in synchronous fashion orcould execute same in asynchronous fashion. FIG. 12 shows an example inwhich only an initial set of business logic for purchase processing isexecuted in synchronous fashion, with subsequent sets of business logicfor inventory processing and accounting processing being executed inasynchronous fashion. Where a plurality of sets of business logic are tobe executed as in the example at FIG. 12, framework service(s) 16 might,upon completion of all set(s) of business logic to be executedsynchronously, return reply message(s) indicating results of suchexecution to client(s). Business logic to be executed asynchronouslymight be executed in background or separately from such client(s) (i.e.,offline of such client(s)).

As shown in FIG. 12, framework service(s) 16 might possess flowdefinition file(s) 23 containing schedule(s) (containing name of singleset of business logic to be executed initially; subject ID(s) ofmessage(s) to be passed to subsequent business logic and manner oflinking (synchronous or asynchronous) in case where there are one ormore subsequent linked set(s) of business logic; and so forth) forexecution of business logic by framework service(s) 16, a separate suchschedule being defined for each of the various message subject IDs.Framework service(s) 16 might receive a single message, upon whichframework service(s) 16 might reference flow definition file(s) 23,might select business logic execution schedule(s) corresponding tosubject ID(s) of such received message, and might execute one or moreset(s) of business logic in accordance with such selected schedule(s).As such selected schedule(s) would indicate at least a single set ofbusiness logic to be executed in direct response to such message, suchframework service(s) might first load and execute such single set ofbusiness logic. If such selected schedule(s) furthermore indicated oneor more subsequent sets of linked business logic and manner(s) oflinking, such framework service(s) might, after executing such initialbusiness logic, execute such subsequent business logic in fashion(s) asdetermined by such manner(s) of linking (i.e., synchronously and/orasynchronously). Moreover, while there are cases where the first set ofbusiness logic and subsequent set(s) of business logic are executed bythe same framework service(s), there are also case where in accordancewith the aforementioned load balancing execution occurs on differentframework service(s).

FIG. 13 shows a simple example of a flow definition file 23.

As shown in FIG. 13, a flow definition file 23 might contain a pluralityof sentences 231, 232, 233, 234 respectively indicating differentbusiness logic execution schedule(s) for different subject ID(s). Suchflow definition file 23 may for example be a text file, in which case itwould be easy to carry out addition, deletion, modification, and/orother such editing of definition sentences 231, 232, 233, 234 using atext editor or the like.

As described within definition sentence 231 at the very top of FIG. 13,each definition sentence may comprise a plurality of subsentencesseparated by a semicolon “;”. The first subsentence may contain inputsubject ID(s), log queue name(s), executable business logic name(s), andso forth. The second and/or following subsentence(s) may each containmessage conversion business logic name(s), output subject ID(s), linkingmode flag(s), and so forth. The first subsentence might relate to asingle set of business logic to be executed in direct response tomessage(s), in which case it would necessarily be indicated in alldefinition sentence(s). The second and/or following subsentence(s) mightrelate to one or more set(s) of subsequent business logic to be executedin cooperation with the initial business logic, in which case it or theywould only be indicated in cases where there is subsequent businesslogic.

The meanings of the items in the first subsentence are as describedbelow.

As used herein, “input subject ID(s)” refers to subject ID(s) ofmessage(s) received by framework service(s).

“Log queue name(s)” refers to name(s) of log queue(s) used in the eventthat such received message(s) is or are written to log(s). For example,“@DEF” might indicate that default log queue(s) is or are to be used,and “@NONE” might indicate that such received message(s) is or are notto be written to log(s).

“Executable business logic name(s)” refers to name(s) of business logicto be executed in direct response to such message(s). In the examples ofdefinition sentences 232 through 234 shown in the drawing, stringsidentical to input subject IDs are used.

The meanings of the items in each the second and/or followingsubsentence(s) are as described below.

“Message conversion business logic name(s)” refers to name(s) of messageconversion business logic executed in order to convert data results fromprocessing of first business logic into message(s) passed to subsequentbusiness logic. In the event that message conversion is unnecessary,“@NONE” might be written here.

“Output subject ID(s)” refers to subject ID(s) of message(s) passed tosubsequent business logic.

“Linking mode flag(s)” indicates or indicate whether subsequent businesslogic is to be executed synchronously or executed asynchronously. Forexample, “SYNC” might indicate synchronous execution, and “ASYNC” mightindicate asynchronous execution.

Second definition sentence 232 in FIG. 13 might apply to the example ofa schedule listed at (1), below.

(1) Execute business logic named “BuySelBuy” in response to message(s)having subject ID “BuySelBuy” (e.g., purchase search request(s)).

Third definition sentence 233 might apply to the example of a schedulelisted at (1)–(3), below.

(1) First, execute business logic named “BuyUpdBuy” (e.g., purchaseupdate processing) in response to message(s) having subject ID“BuyUpdBuy” (e.g., purchase update request(s)).

(2) Next, use conversion business logic named “CnvBuyUpdBuy” to convertthe format of data output by first business logic “BuyUpdBuy”, createmessage(s) having subject ID “InvUpdInv” (e.g., inventory updaterequest), and output to messaging service(s).

(3) Subsequent business logic (e.g., inventory update processing) issynchronously executed, with message(s) “InvUpdInv” which was or wereoutput being processed thereby.

Furthermore, fourth definition sentence 234 might apply to the exampleof a schedule listed at (1)–(5), below.

(1) First, execute business logic named “BuyInsBuy” (e.g., purchaseinspection goods update processing) in response to message(s) havingsubject ID “BuyInsBuy” (e.g., purchase inspection goods updaterequest(s)).

(2) Next, use conversion business logic named “CnvBuyInsBuyl” to convertthe format of data output by first business logic “BuyInsBuy”, createmessage(s) having subject ID “InvUpdInv” (e.g., inventory updaterequest), and output to messaging service(s).

(3) Subsequent business logic (e.g., inventory update processing) isasynchronously executed, with message(s) “InvUpdInv” which was or wereoutput being processed thereby.

(4) Furthermore, use conversion business logic named “CnvBuyInsBuy2” toconvert the format of data output by first business logic “BuyInsBuy”,create message(s) having subject ID “AccDbtBuy” (e.g., accounts payablelog request), and output to messaging service(s).

(5) Subsequent business logic (e.g., accounts payable log processing) isasynchronously executed, with message(s) “AccDbtBuy” which was or wereoutput being received thereby.

Reference is made once again to FIG. 12. By referencing flow definitionfile(s) 23 associated therewith, each framework service 16 can selectand execute business logic 22 corresponding to message(s) which is orare the subject of processing, and moreover, can determine whether thereis a need for subsequent processing, and if there is such a need, cancreate request message(s) for the purpose of subsequent processing andcan return same to messaging service(s) 15.

In such a case, if processing pursuant to other framework thread(s)representing subsequent processing with respect to processing pursuantto a certain framework thread is to be carried out asynchronously,framework service(s) 16 might first input to queue(s) 15 a of messagingservice(s) 15 the results (request message(s) for subsequent processing)of processing of business logic pursuant to the first framework thread,with other framework thread(s) thereafter retrieving such requestmessage(s) from queue(s) 15 a of messaging service(s) 15 to carry outsubsequent processing. In such a case, the framework service(s) 16performing the first processing may be either the same as or differentfrom the framework service(s) 16 performing the subsequent processing.The choice of which of various processes to allocate to which frameworkservice(s) 16 is controlled by the messaging service load balancingfunctionality already described.

Each framework service 16 may employ a message-driven constitution. Thatis, loading of business logic and execution of processing pursuant tosuch business logic may be triggered by the passing of message(s) frommessaging service(s) 15.

In the present embodiment described above, because synchronous andasynchronous are available as possible ways of carrying out linking offramework service business logic and because business logic executionschedules(s) can be controlled simply and as needed by means ofrewritable representation(s) in flow definition file(s), complicatedbusiness logic flow(s) can be defined and can moreover be easily changedas necessary.

Furthermore, in the present embodiment described above, the fact thatmessaging services may be connected in mesh fashion and the fact thatkeep-alive functionality may be employed permits mutual communication ofstatus (message subject ID(s) awaited, whether engaged in ongoingprocess(es), etc.) between or among messaging services, between or amongmessaging service(s) and client(s), and/or between or among messagingservice(s) and framework service(s). In addition, each messaging servicemay record in management table(s) the current status(es) of surroundingclient(s), framework service(s), and/or other messaging service(s).Doing so will make it possible for each messaging service toautomatically select message relay path(s) capable of being usednormally and to deliver message(s) to correct system(s) despite anypossible unavailability of RtFA server(s) due to crashes or the like. Asa result, improved fault tolerance, improvements in system operationalreliability, simpler system expansion, and simpler system maintenanceare permitted.

Furthermore, messaging service(s) may be provided with a plurality ofdata distribution methods, such as P to P and/or P to M, and messagingschedule(s) specifying which message(s) should be sent to which computersystem(s) by which data distribution method(s) may be automaticallyselected in correspondence to status(es) registered in managementtable(s). As a result, flexible messaging service(s) can be provided.

Furthermore, messaging service load balancing functionality makes itpossible to automatically adjust balance in load between or among aplurality of RtFA servers, permitting provision of high performance.

Here, the scope of the present invention should not be limited to thepresent embodiment. It is for example possible to achieve an equivalentsystem through use of other than a JAVA-based platform. Furthermore, thefeatures of the messaging service(s) described above and the features ofthe framework service(s) described above need not necessarily becombined as in the embodiment described above.

Below, some of the detailed functionality which the foregoing embodimentpossesses will be described.

FIG. 14 is a block diagram showing a system for updating flow definitionfile(s) 23.

Framework service(s) 16 may be provided with definition file updatemodule(s) 101, being program module(s) for updating flow definitionfile(s) 23, and such update module(s) 101, upon receipt of reloadcommand(s) 111 from the exterior, may carry out update by overwritingdefinition file(s) 23 currently in use and loaded within main memory ormemories 103 of framework service(s) 16 with new definition file(s) 109stored in external storage device(s) (e.g., disk storage 107) asindicated by arrow 113. New definition file(s) 109 within disk storage107 may be easily edited using text editor(s) 105 or the like. Byinputting the aforementioned reload command(s) 111 at desired time ortimes, definition file(s) 23 within main memory or memories 103 is orare updated to contain the same content as such edited new definitionfile(s) 109. This permits content of definition file(s) 23 to berewritten at desired time or times notwithstanding the fact thatframework service(s) 16 may be operational at such time(s), and permitsoperation of framework service(s) 16 to be made to thereafter reflectsame. Accordingly, changes in scheduling of processing such as changesin what business logic 22 is to be executed and/or whether or notsubsequent processing is to be performed, and/or whether linkedoperation of a plurality of sets of business logic is to be carried outsynchronously or asynchronously, may be accomplished while the system isstill operational.

FIG. 15 shows framework service message conversion processingfunctionality.

Computer program(s) for framework service(s) 16 may for example beconstructed in the JAVA language. As shown in FIG. 15, frameworkservice(s) 16 may be provided with input conversion functionality 102for converting format of input message(s), and output conversionfunctionality 103 for converting format of output message(s). Inputconversion functionality 102 might convert input message(s) in forexample XML format from messaging service(s) 15 into JAVA object format.Output conversion functionality 103 might convert message(s) for outputin JAVA object format to messaging service(s) 15 into XML format. Inputconversion functionality 102 might acquire JAVA class member variable(s)based on representation(s) present in XML DTD(s) (Document TypeDefinition(s)) and might obtain JAVA object member(s) throughinstantiation thereof Furthermore, output conversion functionality 103might form XML DTD(s) and obtain XML member(s) based on JAVA classmember variable(s).

FIG. 16 shows messaging service message queue constitution.

In the foregoing description, message queue(s) 15 a might as easily havebeen unitary queue(s) as not. However, as shown in FIG. 16, messagequeue(s) 15 a may actually comprise three types of queue(s); e.g.,memory queue(s) 153, ring buffer(s) 154, and DB (database) queue(s) 155.Memory queue(s) 153 and/or ring buffer(s) 154 may be provided with RAM151 or other such memory device(s) permitting high-speed access. DBqueue(s) 155 may be provided with nonvolatile large-capacity storagedevice(s) such as hard disk drive(s) (HDD).

Memory queue(s) 153 may be used for temporarily delaying message(s) notrequiring protected storage where component(s) exist to receive resultsof processing of such message(s), such as might be the case for P to Prequest message(s) received from client(s) by messaging service(s). Onthe other hand, DB queue(s) 155 may be used for temporarily delayingmessage(s) requiring protected storage, such as might be the case forrequest message(s) received from framework service(s) by messagingservice(s) for the purpose of asynchronous subsequent processing.Whether protected storage of message(s) is required may be determinedbased on the “protected mode flag(s)” in the constitution of message 10shown in FIG. 2.

Ring buffer(s) 154 may be used for temporarily delaying P to Mmessage(s). Each computer system may, by cycling through ring buffer(s)154, search for and acquire from ring buffer(s) 154 message(s) itawaits. While FIG. 16 illustrates only a single ring buffer 154, thismay in fact represent a set of three ring buffers respectivelycorresponding to the three priority levels “H”, “N”, and “L”.

DB queue(s) 155 may be used for temporarily delaying message(s)requiring protected storage, such as might be the case for requestmessage(s) received from framework service(s) by messaging service(s)for the purpose of subsequent processing

Messaging service(s) may have message queue management functionality 104capable of controlling writing and reading of message(s) to and/or fromthe aforementioned queue(s) 153, 154, 155. Message queue managementfunctionality 104 might give priority to memory queue(s) 153 relative toDB queue(s) 155, checking the former before the latter, and if P to Pmessage(s) exists or exist at memory queue(s) 153, might retrieve suchmessage(s) from memory queue(s) 153 and might send such message(s) to acomputer system awaiting same. Furthermore, if there is not even one Pto P message at memory queue(s) 153, message queue managementfunctionality 104 might check DB queue(s) 155, and if P to P message(s)exists or exist within DB queue(s) 155, might read such message(s) fromDB queue(s) 155 and might send same to a computer system awaiting same.

As shown in FIG. 16, message queue management functionality 104 mightaffix to message(s) M within DB queue(s) 155 status information Sindicating processing status of such message(s), and if such message(s)have been processed might rewrite status information S from“unprocessed” to “processed”. Furthermore, if error(s) resulted inconnection with processing of such message(s), status information Smight be set to “error”. Causes of possible errors include datadiscrepancies, problems with program logic, and so forth. Oncemessage(s) has or have been placed in DB queue(s) 155, such message(s)may be continued to be stored in DB queue(s) 155 without deletiondespite occurrence of system crash, error, or other such problem.

Message queue management functionality 104 may be capable of rewritingstatus information S from “error” to “unprocessed”. In addition, in theevent of occurrence of system crash, error, or other such problem,message queue management functionality 104 might thereafter reread andresend message(s) for which status information S is “unprocessed”. Doingso will ensure that such message(s) is or are definitely processed.Furthermore, tracking of status information S of message(s) associatedwith error(s) might permit causes of errors to be ascertained.

Furthermore, message queue management functionality 104 may be providedwith ability to rewrite status information S from “error” to “processed”in correspondence to external command(s). For example, depending onsystem conditions, there may be circumstances where it is inappropriateto change message(s) from error status to unprocessed status andreoutput same. Furthermore, depending on the severity of the error,there might also be circumstances where it is more appropriate tocorrect such message(s) by means of command input rather than reoutputsame to framework service(s) for processing. In such cases, such abilityto rewrite status information S from “error” to “processed” might beemployed. The foregoing ability to rewrite status information S from“error” to “unprocessed” or to “processed” may be selected freely.

Moreover, message queue management functionality 104 may possess readaddress pointer(s) for ring buffer(s) 154 for each of all of therespective computer system(s) registered in management table(s) 18 (FIG.4), and might use such read address pointer(s) for each such computersystem to cycle through ring buffer(s) 154, find in ring buffer(s) 154 Pto M message(s) awaited by such computer system, and might read suchfound P to M message(s) therefrom and send same to such computer system.

FIGS. 17 and 18 are flowcharts showing operations by which message queuemanagement functionality 104 might store message(s) in message queue(s).

As shown in FIG. 17, upon receipt of message(s) from client(s) (161),message queue management functionality 104 determines which ofnon-transaction mode (NON-TRAN mode) or transaction mode (TRAN mode) isspecified by such client(s) for such message(s) (163). Here, if NON-TRANmode is specified, message queue management functionality 104,immediately upon receipt of message(s), stores such message(s) inmessage queue(s) (i.e., processing of such message(s) is advanced).Conversely, if TRAN mode is specified, message queue managementfunctionality 104, upon receipt of message(s), does not immediatelystore such message(s) in message queue(s) but instead places same indifferent temporary queue(s), and it is only when COMMIT (execute)command(s) is or are sent from client(s) that such message(s) is or arestored in message queue(s) (i.e., that processing of such message(s) isadvanced). In the event that client(s) specifies or specify TRAN modefor issued request message(s), so long as COMMIT command(s) is or arenot issued it will still be possible to thereafter revoke or modify suchrequest message(s).

If as a result of step 163 in FIG. 17 it is determined that NON-TRANmode is specified, message queue management functionality 104 determineswhether such received message(s) is or are P to P or P to M (165). If asa result of such determination such message(s) is or are found to be Pto P, message queue management functionality 104 places such receivedmessage(s) in queue(s) (167). Message(s) placed in queue(s) is or areimmediately read and are sent to framework service(s), where it or theyis or are processed. In the event that as a result of such processingrequest message(s) for subsequent processing is or are returned fromframework service(s), message queue management functionality 104 placessuch request message(s) for subsequent processing in DB queue(s) (169).In addition, message queue management functionality 104 returns toclient(s) successful completion message(s) indicating results ofprocessing of such received message(s) (171).

If as a result of the determination at step 165 such message(s) is orare found to be P to M, message queue management functionality 104determines whether the priority of such received message(s) (FIG. 2) is“H”, “N”, or “L” (173) and stores such received message(s) in ringbuffer(s) corresponding to such determined priority (175, 177, and/or179). P to M message(s) placed in ring buffer(s) is or are sent to allcomputer system(s) awaiting same. In addition, message queue managementfunctionality 104 returns to client(s) successful completion message(s)for such received message(s) (181).

If it is determined at step 163 that TRAN mode is specified, processingproceeds to step 181 indicated in FIG. 18. At step 181, message queuemanagement functionality 104 places such received message(s) intemporary queue(s) different from the foregoing message queue(s). Uponthereafter receiving COMMIT command(s) from client(s) for such receivedmessage(s), message queue management functionality 104 retrieves suchmessage(s) from temporary queue(s), and such message(s) are subjected tothe processing at step 185 and following steps. The processing at step185 and following steps is identical to the processing at step 165 andfollowing steps in FIG. 7 already described.

FIG. 19 shows a message read functionality component of message queuemanagement functionality 104.

As shown in FIG. 19, message queue management functionality 104 ofmessaging service(s) 15 may store message(s) respectively received fromclient(s) and framework service(s) in message queue(s) 15 a havingconstitution(s) as described above. Particularly with respect to the wayin which message(s) is or are retrieved from memory queue(s) 153 and/orDB queue(s) 155 of message queue(s) 15 a shown in FIG. 16, message queuemanagement functionality 104 may display the two functionalitiesrepresented by prioritized mode 104 a and sequence protection mode 104b. Prioritized mode 104 a is such that order(s) in which message(s) isor are retrieved from message queue(s) is or are controlled based onmessage priority or priorities. On the other hand, sequence protectionmode 104 b is such that prescribed order(s) of processing of a pluralityof messages is or are protected by prohibiting retrieval of subsequentmessage(s) stored in message queue(s) until completion of processing byframework service(s) of message(s) previously retrieved from suchmessage queue(s). Whether prioritized mode 104 a is to be carried out orsequence protection mode 104 b is to be carried out may be selected foreach message queue in correspondence to respective message subject ID(s)and/or previously established mode setting(s) for respective messagequeue(s). Sequence protection mode 104 b may be used for example whererespective request messages for sales processing are coming from aplurality of clients, if it is desired to preserve prescribed processingorder(s) of the sort such that sales processing request(s) coming latermight be executed after completion of previous request(s) for salesprocessing.

FIG. 20 shows constitution(s) of storage area(s) for prioritized mode104 a. FIG. 21 shows flow of operations in prioritized mode 104 a.

As indicated in FIG. 20, prioritized mode 104 a might employ two stackmemories represented by sortable stack 211 and simple stack 213, and forexample three entries 215H, 215N, and 215L respectively corresponding tothe three priority levels “H”, “N”, and “L”. Note that it is alsopossible to have a greater number of entries. For example, in additionto the three entries shown in the drawing, another entry might be addedwhich corresponds to “H”.

Respective entries 215H, 215N, and 215L might initially be respectivelyset for example to index values such as the “5”, “3”, and “1” shown inthe drawing. Initial index values might be such that the higher thevalue the higher the priority level which is indicated.

In addition, all of the entries 215H, 215N, and 215L might, as shown inthe drawing, initially be present at sortable stack 211, with simplestack 213 being empty.

Sortable stack 211 might be such that the array represented by theplurality of indices present therein is automatically rearranged inorder of increasing index so as to cause the entry with the highestindex to be at the top and the entry with the lowest index to be at thebottom. Accordingly, entries may be removed from sortable stack 211 suchthat the higher the index of an entry the sooner it is removedtherefrom.

Simple stack 213 might be such that entries placed therein later arejust placed on top of entries previously placed therein. Accordingly,entries may be removed from simple stack 213 such that the later anentry was placed therein the sooner it will be removed therefrom.

In accordance with the flow of operations indicated in FIG. 21,prioritized mode 104 a may control order(s) in which message(s) is orare removed from message queue(s) (memory queue(s) 153 and/or DBqueue(s) 155) through movement of entries between sortable stack 211 andsimple stack 213, and manipulation of indices of entries.

Below, the flow of operations indicated in FIG. 21 will be described.First, prioritized mode 104 a removes the topmost entry (i.e., the entryhaving the highest index) from sortable stack 211 (221) and places thatentry in simple stack 213 (223). Next, prioritized mode 104 a checks tosee whether message queue(s) contains or contain message(s) havingpriority or priorities matching the priority of the topmost entry insimple stack 213 (225). If the result is that there is or are nomatching message(s), processing proceeds to step 221. Furthermore, if asa result of the foregoing check matching message(s) is or are found,then prioritized mode 104 a removes such matching message(s) from suchmessage queue(s) (227). Message(s) removed therefrom are processed atsome framework service(s). Prioritized mode 104 a then checks to seewhether the number of entries present at simple stack 213 is one (229).If it is as a result found that the number of entries at simple stack213 is two or greater, then all entries are removed in order from simplestack 213 and are placed on sortable stack 211 (237). In addition, formessage(s) removed from message queue(s) at step 227, prioritized mode104 a returns to client(s) reply message(s) indicating processingresults from framework service(s) (239).

If as a result of the check at step 229 it is found that the number ofentries at simple stack 213 is one, then prioritized mode 104 adecreases by 1 the index of the entry in simple stack 213 (231). Inaddition, prioritized mode 104 a checks to see whether the index afterbeing so decreased is “−1” (233), and if it is not “−1” then processingproceeds to step 237, but if it is “−1” then that index is reset to itsinitial value (235) and processing thereafter proceeds to step 237.

The foregoing operations permit message(s) to be retrieved from messagequeue(s) in an order such that the order in which messages are stackedwithin message queue(s) is corrected to reflect priority or prioritiesof messages. That is, if the order, in terms of priorities, of messagespresent within a message queue is, for example as indicated at FIG. 20,“H”, “H”, “L”, “H”, “H”, “H”, “N”, the order in which those messages areretrieved from that message queue might, in terms of priorities, be “H”,“H”, “N”, “H”, “H”, “H”, “L”.

FIG. 22 shows flow of operations in sequence protection mode 104 b.

As shown in FIG. 22, sequence protection mode 104 b is such that uponissuance of a message retrieval request (241), message queue(s) is orare first locked (243, 245, 257), prohibiting retrieval of othermessage(s) from message queue(s). Next, sequence protection mode 104 breads one message from a message queue (247, 249). The message so readis processed at some framework service(s) (251), and commit (or rollbackif processing does not complete successfully) operation(s) pursuant toany database update(s) appropriate to such processing is or are carriedout (253). Sequence protection mode 104 b thereafter releases the lockon message queue(s) (255).

The foregoing operations permit a prescribed order of processing ofmessages to be preserved due to the fact that processing of a nextmessage is executed after completion of processing of a previousmessage.

FIG. 23 shows message discrimination functionality at a frameworkservice 16.

As shown in FIG. 23, framework service(s) 16 may possess messagediscrimination business logic 106, message discrimination business logic106 being executed upon receipt of message(s) from messaging service(s)15. Message discrimination business logic 106 might search flowdefinition file(s) 23 associated with such framework service(s) fordefinition sentence(s) containing subject ID(s) matching subject ID(s)of such received message(s). If matching definition sentence(s) is orare found, executable business logic 22 indicated by such definitionsentence(s) might then be executed. However, if no matching definitionsentence is found, message discrimination business logic 106 mightreturn to messaging service(s) 15 reply message(s) indicating error(s)to the effect that processing could not be performed, and such replymessage(s) might be sent to client(s). As has already been described,because messaging service(s) 15 only sends respective message(s) tocomputer system(s) awaiting such message(s) based on management table(s)18 (FIG. 4), as a general principle there should be no situation where aparticular message is mistakenly sent to a wrong framework service.However, even in the unlikely event that a particular message fromclient(s) is mistakenly sent to wrong framework service(s), because suchclient(s) would immediately receive reply message(s) indicating error(s)to the effect that processing could not be performed there would be noextended delay and processing could quickly proceed to the nextoperation.

Furthermore, framework service(s) 16 may be provided with a serviceunavailable mode capable of granting permission for processing byframework service(s) only to message(s) having previously registeredidentification information, in which case if such mode was selected thenupon receipt from client(s) of message(s) having identificationinformation which is not previously registered, message(s) might bereturned to client(s) to the effect that such message(s) will not beaccepted.

FIG. 24 shows message conversion business logic possessed by frameworkservice(s).

As shown in FIG. 24, framework service(s) 16 may have one or more setsof message conversion business logic 105. Such set(s) of messageconversion business logic 105 might for example be the “CnvBuyUpdBuy”,“CnvBuyInsBuy1”, and/or “CnvBuyInsBuy2” indicated at definitionsentences 233 and 234 of flow definition file 23 shown in FIG. 13 or thelike. Each set of message conversion business logic 105 might correspondto one previously established set of business logic BL1. Upon executionof a particular set of business logic BL1 in accordance with aparticular definition sentence, message conversion business logic 105corresponding thereto might be executed following same. Messageconversion business logic 105 may be provided with format conversionfunctionality such that format(s) for processing results message(s)output from first business logic BL1 is or are made to conform toformat(s) for message(s) input to subsequent business logic BL2, andmessage filtering functionality such that whether message(s) output fromfirst business logic BL1 is or are to be input to subsequent businesslogic BL2 is determined in correspondence to parameter(s) associatedwith such message(s). For example, if a configuration of parameters formessages handled by first business logic BL1 is different from aconfiguration of parameters for messages handled by subsequent businesslogic BL2, message conversion business logic 105 might convert theformer configuration of parameters to the latter configuration ofparameters. Furthermore, there are situations (e.g., denial of request,unsuccessful attempt to update database, rollback of transaction, etc.)where the special nature of a message output from first business logicBL1 would cause execution of subsequent business logic BL2 to bemeaningless. In such a case, message conversion business logic 105 mightby virtue of its message filtering functionality omit creation ofmessage(s) for input to subsequent business logic BL2. Here, messagequeue(s) capable of temporarily holding message(s) may be interposedbetween first business logic BL1 and message conversion business logic105, and/or between message conversion business logic 105 and subsequentbusiness logic BL2.

The foregoing descriptions are merely illustrative examples for purposesof describing the present invention. The present invention is notlimited to the foregoing embodiments, but may also be carried out in thecontext of a great many other variations on system configuration.

1. A framework system connected so as to be capable of communicationwith one or more clients, said system comprising: a plurality of sets ofbusiness logic; one or more framework services, one or more of which isor are associated with at least one of the sets of business logic andwhich, responsive to one or more request messages from at least one ofthe client or clients, is or are capable of executing one or moreselected sets among the sets of business logic and outputting one ormore reply messages to at least one of the client or clients; one ormore messaging services interposed between one or more of the client orclients and one or more of the framework service or services and capableof relaying one or more messages between the client or clients and theframework service or services; and one or more flow definition filesassociated with one or more of the framework service or services; atleast one of the request message or messages comprising at least onesubject ID identifying at least one subject of at least one of therequest message or messages; at least one of the flow definition file orfiles comprising a plurality of definition sentences respectivelycorresponding to a plurality of different subject IDs, each suchdefinition sentence indicating one or more schedules for execution ofone or more prescribed sets of business logic; and at least one of theframework service or services, upon receipt of at least one of therequest message or messages from the messaging service or services,referencing at least one definition sentence present within at least oneof the definition file or files and corresponding to at least onesubject ID of at least one of the request message or messages, andselecting at least one set of business logic for execution in accordancewith at least one execution schedule indicated by at least one of thereferenced definition sentence or sentences; wherein at least onedefinition sentence present within at least one of the flow definitionfile or files indicates at least one linked execution schedule forlinked execution of a plurality of sets of business logic comprising oneset of first business logic and at least one set of subsequent businesslogic; at least one of the linked execution schedule or schedulescomprising indication of the state or states of one or more linking modeflags for selection of synchronous or asynchronous execution of at leastone of the set or sets of subsequent business logic; at least one of theframework service or services, in the event of execution of theplurality of sets of business logic in accordance with at least one ofthe linked execution schedule or schedules, executing at least one ofthe set or sets of subsequent business logic synchronously orasynchronously with respect to execution of the set of first businesslogic in accordance with at least one of the linking mode flag or flagspresent within at least one of the linked execution schedule orschedules.
 2. A framework system according to claim 1 further comprisingone or more flow definition update components capable of updating atleast one of the flow definition file or files while at least one of theframework service or services is operational.
 3. A framework systemaccording to claim 1 wherein at least one of the linked executionschedule or schedules comprises information concerning the set of firstbusiness logic and information concerning one or more secondary requestmessages for at least one of the set or sets of subsequent businesslogic; the framework system, in the event of execution of the pluralityof sets of business logic in accordance with at least one of the linkedexecution schedule or schedules, executing the set of first businesslogic, thereafter using the results of execution of the set of firstbusiness logic to create at least one of the secondary request messageor messages, sending at least one of the secondary request message ormessages to at least one of the messaging service or services, andthereafter, upon receipt of at least one of the secondary requestmessage or messages from at least one of the messaging service orservices, executing at least one of the set or sets of subsequentbusiness logic in accordance with at least one execution schedule of atleast one definition sentence corresponding to at least one of thesecondary request message or messages.
 4. A framework system accordingto claim 3 wherein at least one of the messaging service or services isequipped with one or more nonvolatile message queues capable ofprotected storage of at least one of the secondary request message ormessages; at least one of the message queue or queues being capable ofpreventing deletion of at least one of the secondary request message ormessages by continuing to store at least one of the secondary requestmessage or messages after one or more of the secondary request messageor messages has or have been sent to one or more of the frameworkservice or services.
 5. A framework system according to claim 4 whereinat least one of the messaging service or services is capable ofresending at least one of the secondary request message or messagesstored in at least one of the message queue or queues to the frameworksystem as necessary.
 6. A framework system connected so as to be capableof communication with one or more clients, said system comprising: aplurality of messaging services mutually connected in mesh fashion andcomprising at least one messaging service which is connected to at leastone of the one or more clients; and a plurality of framework servicesrespectively connected to the plurality of messaging services; theplurality of framework services respectively being capable of awaitingone or more request messages having one or more preestablished subjectIDs andlupon receipt of at least one of the request message or messageshaving preestablished subject ID or IDs, of processing the receivedrequest message or messages and of outputting one or more reply messagesto at least one of the client or clients; and the plurality of messagingservices being capable of relaying one or more messages between theclient or clients and the plurality of framework services and beingcapable of relaying one or more messages between or among the pluralityof framework systems; wherein at least one of the messaging services hasits own respective management table; one or more subject IDs of one ormore messages awaited by one or more of the framework systems connectedto the messaging services and one or more subject IDs of one or moremessages respectively awaited by one or more messaging services otherthan the at least one messaging service but connected to the at leastone messaging service being registered in at least one of the managementtable or tables respective to the messaging service or services; and theat least one messaging service, at one or more times when at least onemessage is received, referencing at least one of the management table ortables respective thereto, searching for one or more of the frameworkservices or one or more of the other messaging services that awaits orawait at least one subject ID matching at least one subject ID of the atleast one received message, and relaying the at least one receivedmessage to at least one of the framework service or services or othermessaging service or services found as a result of the search.
 7. Aframework system according to claim 6 wherein the messaging services arerespectively capable of monitoring operation of one or more othermessaging services; and, in the event that normal operation of at leastone other messaging service fails to be detected, one or more messagesis or are relayed to one or more normally operating other messagingservices instead of to the at least one other messaging service.
 8. Aframework system according to claim 6 wherein the messaging services arerespectively capable of monitoring state or states of one or more of theframework services respectively connected to the messaging services; andselection of whether to relay at least one of the request message ormessages from at least one of the client or clients to at least one ofthe respective framework services connected to the respective messagingservices or to one or more other messaging services is made incorrespondence to the monitored state or states.
 9. A framework systemaccording to claim 6 wherein at least one of the messaging servicescommunicates, to one or more messaging services other than the at leastone messaging service but connected to the at least one messagingservice, at least one subject ID of at least one message awaited by theat least one messaging service based on content of at least one of themanagement table or tables respective to the messaging service orservices.
 10. A framework system according to claim 9 wherein at leastone of the messaging services, upon receipt of communication, from oneor more respective messaging services other than the at least onemessaging service but connected to the at least one messaging service,of at least one subject ID of at least one message awaited by one ormore of the other messaging services, additionally registers thecommunicated content in at least one of the management table or tablesrespective to the messaging service or services if the communicatedcontent is not yet registered in one or more of the management table ortables respective thereto.
 11. A framework system connected so as to becapable of communication with one or more clients, said systemcomprising: one or more framework services, one or more of which is orare capable of processing one or more request messages from at least oneof the client or clients and of outputting one or more reply messages toat least one of the client or clients; and one or more messagingservices interposed between one or more of the client or clients and oneor more of the framework service or services and capable of relaying oneor more messages between the client or clients and the framework serviceor services; the request message or messages being prioritized in aparticular fashion; at least one of the messaging service or servicescomprising one or more message queues capable of temporarily delaying atleast one of the request message or messages and one or more queuemanagement components capable of managing input and/or output of atleast one of the message queue or queues; and at least one of the queuemanagement component or components being provided with a prioritizedmode by which, at one or more times when a plurality of messages havebeen stored in one or more of the message queue or queues, the order ororders in which the plurality of messages are output from the messagequeue or queues is or are controlled in correspondence to the respectivepriority or priorities of the respective message or messages, and with asequence protection mode by which, at one or more times when a pluralityof messages have been stored in one or more of the message queue orqueues, retrieval of one or more other messages stored in the messagequeue or queues is prohibited until completion of processing at one ormore of the framework service or services of at least one messagepreviously retrieved from the message queue or queues; wherein at leastone definition sentence present within at least one of the flowdefinition file or files indicates at least one linked executionschedule for linked execution of a plurality of sets of business logiccomprising one set of first business logic and at least one set ofsubsequent business logic; at least one of the linked execution scheduleor schedules comprising indication of the state or states of one or morelinking mode flags for selection of synchronous or asynchronousexecution of at least one of the set or sets of subsequent businesslogic; at least one of the framework service or services, in the eventof execution of the plurality of sets of business logic in accordancewith at least one of the linked execution schedule or schedules,executing at least one of the set or sets of subsequent business logicsynchronously or asynchronously with respect to execution of the set offirst business logic in accordance with at least one of the linking modeflag or flags present within at least one of the linked executionschedule or schedules.
 12. A method of operating a framework systemconnected so as to be capable of communication with one or more clients,said method comprising: a step wherein at least one request message isreceived from at least one of the client or clients; a step wherein atleast one of the received request message or messages is placed in oneor more message queues; a step wherein at least one request message isretrieved from at least one of the message queue or queues; and a stepwherein at least one retrieved request message is processed; theretrieval step employing a prioritized mode by which, at one or moretimes when a plurality of messages have been stored in one or more ofthe message queue or queues, the order or orders in which the pluralityof messages are output from the message queue or queues is or arecontrolled in correspondence to priority or priorities of respectivemessages, and employing a sequence protection mode by which, at one ormore times when a plurality of messages have been stored in one or moreof the message queue or queues, retrieval of one or more other messagesstored in the message queue or queues is prohibited until completion ofprocessing of at least one message previously retrieved from the messagequeue or queues; wherein at least one definition sentence present withinat least one of the flow definition file or files indicates at least onelinked execution schedule for linked execution of a plurality of sets ofbusiness logic comprising one set of first business logic and at leastone set of subsequent business logic; at least one of the linkedexecution schedule or schedules comprising indication of the state orstates of one or more linking mode flags for selection of synchronous orasynchronous execution of at least one of the set or sets of subsequentbusiness logic; at least one of the framework service or services, inthe event of execution of the plurality of sets of business logic inaccordance with at least one of the linked execution schedule orschedules, executing at least one of the set or sets of subsequentbusiness logic synchronously or asynchronously with respect to executionof the set of first business logic in accordance with at least one ofthe linking mode flag or flags present within at least one of the linkedexecution schedule or schedules.